Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zha switch schedule update state #16621

Merged
merged 2 commits into from
Sep 21, 2018

Conversation

Adminiuga
Copy link
Contributor

Description:

switch.zha is a non-polled entity should_poll = False so whenever the switch is successfully turned on or off, it should schedule state update, otherwise the state wouldn't be updated in the UI

Checklist:

  • The code change is tested and works locally.
  • Local tests pass with tox. Your PR cannot be merged unless tests pass

if turning switch On or Off operation was successful, then schedule
state update
@ghost ghost added the in progress label Sep 14, 2018
return

self._state = 1
self.async_schedule_update_ha_state()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't do this, and neither should we change self._state. We depend on attribute_updated to push the state change to us

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely sure relying on attribute_updated is a proper channel for this kind of state updated, especially when we're triggering the change.
We do send a ZCL command and we do know the transmission hasn't timed out, in other words device has acknowledge reception of the command.
The problem with attribute_updated it relies on attribute reporting configuration, so if for whatever reason zha.configure_reporting() was unsuccessful, this makes the switch unusable, as I never can change the state (because the feedback loop through attribute_updated is broken) even though I can control the switch and switch can successfully receive my commands.
attribute_updated channel is more for externally originated events, like user toggling the switch from the button on the actual physical device.

@rcloran what do you think?

Copy link
Contributor Author

@Adminiuga Adminiuga Sep 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also want to implement attribute_updated() method for fan.zha.ZhaFan class, because it is nice for HA state to be in sync with the actual state of the device, since the fan is often operated externally from the remote/wall switch.
I'd like to understand why it is fundamentally wrong with updating self._state in the service calls and in attribute_updated() method. Both are executed in the event loop, so there shouldn't be any race conditions. I'm not always getting attribute report triggering the attribute_update() with King of Fans zigbee fan, so relying solely on atribute_updated() to update self._state would likely render Fan inoperable from HA

Copy link
Member

@balloob balloob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems fine if we are guaranteed that command has been received.

@balloob balloob merged commit 9fdf123 into home-assistant:dev Sep 21, 2018
@ghost ghost removed the in progress label Sep 21, 2018
@Adminiuga
Copy link
Contributor Author

Thank you.
Yes, if the command is not received by the far end device or we do not receive ACK, then zigpy raises DeliveryError exception and in this case we do not update self._state.

@Adminiuga Adminiuga deleted the zha-switch-update-state branch September 21, 2018 12:54
@balloob balloob mentioned this pull request Sep 28, 2018
@home-assistant home-assistant locked and limited conversation to collaborators Feb 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla-signed integration: zha small-pr PRs with less than 30 lines.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants